A typical conventional SSL VPN gateway is configured to provide browser-based access to the internal resources of an enterprise network. Such internal resources may comprise servers, computers or other processing devices, from many different vendors, and running a wide variety of different protocols. Inbound transactions directed to the gateway are generally initiated using standard protocols such as hypertext transfer protocol (HTTP) or HTTP secure sockets (HTTPS). An SSL VPN gateway is not itself a firewall, but is instead usually located within the enterprise behind the firewall.
Examples of conventional SSL VPN gateways include the SA 700, SA 2000, SA 4000, SA 6000 and SA 6000 SP products commercially available from Juniper Networks, Inc. of Sunnyvale, Calif., USA, the EX-2500, EX-1500 and EX-750 products commercially available from Aventail Corp. of Seattle, Wash., USA, and the Permeo Base5 product commercially available from Permeo Technologies, Inc. of Austin, Tex., USA.
A significant drawback associated with conventional VPN gateways of the type listed above is that it can be difficult to handle alarms generated by internal resources of the enterprise. Such resources often comprise products from multiple vendors. Each vendor may have an external service provider that provides customer support for the products of that vendor. A given service provider may comprise, for example, technicians and expert systems that can process the alarms to resolve whatever problems may exist in the corresponding vendor products. Exemplary expert systems that may be used to process alarms are described in U.S. patent application Ser. No. 10/939,694, filed Sep. 13, 2004 in the name of inventors S. Ganesh et al. and entitled “Distributed Expert System for Automated Problem Resolution in a Communication System,” which is commonly assigned herewith and incorporated by reference herein.
Generally, the conventional SSL VPN gateways are not configured to deliver alarms from multi-vendor products to their associated service providers, or to allow the service providers access to the products that generated the alarms. In many cases, a customer may have to call the service provider in order to let them know of a problem that has resulted in an alarm. The customer would then have to provide explicit authorization to allow a technician or expert system of the service provider to gain access to the product in order to resolve the problem.
Also, conventional SSL VPN gateways are typically designed to authenticate single users. It is impractical to authenticate the hundreds or even thousands of technicians that may be associated with the service providers that support the various multi-vendor products in a given enterprise. Service provider technicians may have to use hardware tokens or other similar mechanisms to obtain access to an enterprise network, and each service provider technician would have to use different sets of hardware tokens for each customer, which is impractical and expensive. Moreover, authenticating large pools of multi-vendor service provider technicians can place an excessive burden on the administration, authorization and authentication (AAA) server of a given enterprise, which is clearly undesirable.
It is therefore apparent that a need exists for an improved SSL VPN gateway, which can provide more efficient handling of alarms from multi-vendor products that are part of the internal resources of an enterprise network.